Two bug fixes - disallow "new (int, int)()" and induce a failure if ValueTuple is not a struct. #14161

VSadov · 2016-09-28T23:29:05Z

Fixes: #10891 - Forbid constructing tuples via "new"
Fixes: #11689 - Enforce that ValueTuple types are structs

Note that #11689 requires validation that ValueTuple is a value type only in common cases, That is - to convey that cases where ValueTuple happens to be a Class, Enum, Delegate, etc are clearly not supported.

From the language prospective, tuples are value types composed of their elements. That is visible through the semantics of definite assignment, conversions, nullable lifting, async capturing and so on. This change intentionally introduces emit failures when underlying ValueTuple types are not structs.

This is only C# part.
VB will need exactly same fixes ported.

gafter · 2016-09-29T00:18:10Z

src/Compilers/CSharp/Portable/Binder/Binder_Expressions.cs

@@ -3181,6 +3181,12 @@ protected BoundExpression BindObjectCreationExpression(ObjectCreationExpressionS
 {
 var type = BindType(node.Type, diagnostics);

+ if (node.Type.Kind() == SyntaxKind.TupleType)


Can you please move this constraint into the parser? It is likely to be specified as a syntactic constraint. The syntax new (x, y) is reasonably likely to be a work item in the not too distant future (#35). Having this handled in the parser would make the next person's job much easier. #Resolved

Will try move it to parser. #Resolved

gafter · 2016-09-29T00:19:47Z

src/Compilers/CSharp/Portable/Emitter/Model/PEModuleBuilder.cs

@@ -21,7 +21,7 @@ internal abstract class PEModuleBuilder : PEModuleBuilder<CSharpCompilation, Sou
 // TODO: Need to estimate amount of elements for this map and pass that value to the constructor. 
 protected readonly ConcurrentDictionary<Symbol, Cci.IModuleReference> AssemblyOrModuleSymbolToModuleRefMap = new ConcurrentDictionary<Symbol, Cci.IModuleReference>();
 private readonly ConcurrentDictionary<Symbol, object> _genericInstanceMap = new ConcurrentDictionary<Symbol, object>();
- private readonly ConcurrentSet<ErrorTypeSymbol> _reportedErrorTypesMap = new ConcurrentSet<ErrorTypeSymbol>();
+ private readonly ConcurrentSet<TypeSymbol> _reportedErrorTypesMap = new ConcurrentSet<TypeSymbol>();


I think this set should use an identity comparer. #Resolved

Will change to identity.
Note that this is an optimization for the number of errors spitted out in extremely rare and badly broken cases. I do not think it makes a lot of difference either way. #Resolved

VSadov · 2016-09-30T05:47:52Z

@dotnet-bot test perf_correctness_prtest please
@dotnet-bot test windows_release_unit64_prtest please

gafter

This looks good as far as it goes. However I believe we should also forbid new'ing a nullable tuple type as well, i.e. new (int, int)?() should be an error. Such an expression can be replaced by null.

gafter · 2016-09-30T19:05:38Z

src/Compilers/CSharp/Portable/Parser/LanguageParser.cs

@@ -10676,7 +10676,13 @@ private ExpressionSyntax ParseArrayOrObjectCreationExpression()
 SyntaxFactory.MissingToken(SyntaxKind.CloseParenToken));
 }

- return _syntaxFactory.ObjectCreationExpression(@new, type, argumentList, initializer);
+ var objectCreation = _syntaxFactory.ObjectCreationExpression(@new, type, argumentList, initializer);
+ if (type.Kind == SyntaxKind.TupleType)


Might be nicer to put the error on the tuple type. #ByDesign

I tried to figure what is at fault here - the "new" or the tuple literal. And ended up deciding to flag the whole thing since it is the combination that is invalid.

In reply to: 81399515 [](ancestors = 81399515)

gafter · 2016-09-30T19:12:02Z

src/Compilers/CSharp/Test/Syntax/Parsing/StatementParsingTests.cs

@@ -2597,7 +2597,7 @@ class C1
 {
 static void Test(int arg1, (byte, byte) arg2)
 {
- (int, int) t1 = new(int, int)();
+ (int, int)? t1 = new(int, int)?();


Can you please modify the test to assert what the diagnostics are? This syntax should also not work (i.e. a nullable tuple type syntax with new should also be a syntax error). #Resolved

What about new (int, int)[0] t1 or new (int, int)?[0] t1 ? #ByDesign

I think we need more design discussions for additional restrictions.

So far we agreed to not allow new directly with tuple types.
This change implements that decision.
It started with not being able to do that anyways for tuple types with 7+ elements. With nullables or arrays there are no problems on their own, so we need to formalize another motivation.

We should discuss addition restrictions more comprehensively, just to be sure there is a common rational reason for all the cases and that we covered them all.
#WontFix

Just to mention another case:
new (int, int)?(<value>) is also legal

Nullable<T> has a ctor that takes T, so as long as <value> converts to T, the code above has meaning.
So will need to decide whether to allow it or not.

#WontFix

Per current rules only a "new" applied immediately to a tuple type is not permitted. So this is valid. For now.

I am afraid generalizing the rule to a wider range of syntax is not so straightforward and unambiguous. I expect a range of opinions and valid reasons why we need to go one way or another from here, so I am not brave enough to guess :-)

If we want to cover a wider range of syntax, we need to tweak the design and implement it in another change. #WontFix

Agreed, but please do check the specific diagnostics here. #Resolved

This test does not result in any diagnostics. (only valid cases are here) and there is validation that we do not have diagnostics.

Once some of this cases become errors, the test will catch that. #Resolved

Oh, I mistakenly thought it was asserting there were errors.

Wont Fix for this PR.
We need a better understanding of desired design for this change

In reply to: 81405544 [](ancestors = 81405544)

cston · 2016-09-30T21:01:57Z

src/Compilers/CSharp/Portable/Binder/Binder_Expressions.cs

+ if (node.Type.Kind() == SyntaxKind.TupleType)
+ {
+ Debug.Assert(node.HasErrors, "new <tuple type> should be a syntax error");
+ return BadExpression(node, LookupResultKind.NotCreatable);


Should type be used for the type? #WontFix

Considering that it might parse into something else in the future, I do not want to bind the type. #WontFix

Binding the type might result in more diagnostics, or opposite - something that uses the expression type may actually work. And that will change once we change parsing. It seems to be better if we do not bind. #Resolved

Aren't we already binding the type at line 3182? #Resolved

Ah. I see. I meant to move this to after the check. Somehow type binding is still there. Will fix.

In reply to: 81443846 [](ancestors = 81443846)

Thanks for noticing this! Fixed.

In reply to: 81451427 [](ancestors = 81451427,81443846)

cston · 2016-09-30T21:07:02Z

src/Compilers/CSharp/Portable/Emitter/Model/PEModuleBuilder.cs

@@ -21,7 +21,7 @@ internal abstract class PEModuleBuilder : PEModuleBuilder<CSharpCompilation, Sou
 // TODO: Need to estimate amount of elements for this map and pass that value to the constructor. 
 protected readonly ConcurrentDictionary<Symbol, Cci.IModuleReference> AssemblyOrModuleSymbolToModuleRefMap = new ConcurrentDictionary<Symbol, Cci.IModuleReference>();
 private readonly ConcurrentDictionary<Symbol, object> _genericInstanceMap = new ConcurrentDictionary<Symbol, object>();
- private readonly ConcurrentSet<ErrorTypeSymbol> _reportedErrorTypesMap = new ConcurrentSet<ErrorTypeSymbol>();
+ private readonly ConcurrentSet<TypeSymbol> _reportedErrorTypesMap = new ConcurrentSet<TypeSymbol>(ReferenceEqualityComparer.Instance);


Why use reference equality rather than Equals? Won't we report more errors as a result? #ByDesign

These are always original types or error types, which are equal by identity. #Resolved

I did not realize that, just followed Neal's advise, but yes, they are definitions.

In reply to: 81423689 [](ancestors = 81423689)

In general, error types are not equal by identity. Please revert the change.

In reply to: 81434867 [](ancestors = 81434867,81423689)

Will revert

In reply to: 81654084 [](ancestors = 81654084,81434867,81423689)

gafter · 2016-09-30T22:33:40Z

src/Compilers/CSharp/Test/Syntax/Parsing/StatementParsingTests.cs

@@ -2597,7 +2597,7 @@ class C1
 {
 static void Test(int arg1, (byte, byte) arg2)
 {
- (int, int) t1 = new(int, int)();
+ (int, int)? t1 = new(int, int)?();


Oh, I mistakenly thought it was asserting there were errors.

… type syntax

VSadov · 2016-10-03T21:09:59Z

@dotnet/roslyn-compiler PING.

jcouv · 2016-10-03T21:19:39Z

src/Compilers/CSharp/Portable/Emitter/Model/PEModuleBuilder.cs

+ {
+ diagnostics.Add(new CSDiagnostic(new CSDiagnosticInfo(ErrorCode.ERR_PredefinedValueTupleTypeMustBeStruct, namedTypeSymbol.MetadataName), syntaxNodeOpt == null ? NoLocation.Singleton : syntaxNodeOpt.Location));
+ }
+ }


Consider extracting this block to a method.
Also, there may be a simpler way to report the diagnostic. #Resolved

jcouv · 2016-10-03T21:21:00Z

src/Compilers/CSharp/Portable/Emitter/Model/PEModuleBuilder.cs

+ // this should never happen, in theory,
+ // but if it does happen we should make it a failure.
+ var declaredBase = namedTypeSymbol.BaseTypeNoUseSiteDiagnostics;
+ if (declaredBase.SpecialType != SpecialType.System_ValueType && !declaredBase.IsErrorType())


Is there a reason not to simply check namedTypeSymbol.IsValueType? Note that TupleTypeSymbol.IsValueType already defaults to true if the underlying type is an error type. #ByDesign

namedTypeSymbol is not necessarily a tuple and many types would default to be classes or whatever.
We do not want Enums, which are value types, so checking for a base ValueType is actually simpler and more precise.

In reply to: 81642661 [](ancestors = 81642661)

cston · 2016-10-03T21:21:15Z

src/Compilers/CSharp/Portable/CSharpResources.resx

+ <value>Predefined type '{0}' must be a struct.</value>
+ </data>
+ <data name="ERR_NewWithTupleTypeSyntax" xml:space="preserve">
+ <value>"new" cannot be used with tuple type '{0}'. Use a tuple literal expression instead.</value>


Resource strings typically using single quotes rather than double quotes for keywords: 'new' rather than "new" #Resolved

fixed

In reply to: 81642694 [](ancestors = 81642694)

jcouv · 2016-10-03T21:23:28Z

src/Compilers/CSharp/Portable/Parser/LanguageParser.cs

+ var objectCreation = _syntaxFactory.ObjectCreationExpression(@new, type, argumentList, initializer);
+ if (type.Kind == SyntaxKind.TupleType)
+ {
+ objectCreation = this.AddError(objectCreation, objectCreation, ErrorCode.ERR_NewWithTupleTypeSyntax, type.ToString());


If we have add this error during parsing, why do we also need special handling in BindObjectCreationExpression? #Resolved

By default we do attempt to bind syntax even if it has errors. We should not in his case. It is intentional that it means nothing now because we expect it to mean a different thing in the future.

In reply to: 81643102 [](ancestors = 81643102)

jcouv · 2016-10-03T21:25:02Z

src/Compilers/CSharp/Portable/Symbols/Tuples/TupleTypeSymbol.cs

- // we need to have some support for classes, but most common case will be struct
- // in broken scenarios (ErrorType, Enum, Delegate, whatever..) we will just default to struct.
- return _underlyingType.TypeKind == TypeKind.Class ? TypeKind.Class : TypeKind.Struct;
+ // From the language prospective tuple is a value type 


prospective [](start = 37, length = 11)

s/prospective/perspective/ #Resolved

fixed

In reply to: 81643451 [](ancestors = 81643451)

jcouv · 2016-10-03T21:28:41Z

src/ExpressionEvaluator/CSharp/Test/ExpressionCompiler/TupleTests.cs

@@ -261,8 +261,8 @@ .maxstack 6
 IL_002f: ldstr ""y""
 IL_0034: call ""(int A, int B) Microsoft.VisualStudio.Debugger.Clr.IntrinsicMethods.GetVariableAddress<(int A, int B)>(string)""
 IL_0039: ldloc.0
- IL_003a: stind.ref
- IL_003b: ret
+ IL_003a: stobj ""System.ValueTuple<int, int>""


I didn't understand why this IL changed. What caused this? #ByDesign

Tuple type was not a struct here

In reply to: 81644123 [](ancestors = 81644123)

It is an error type because testcase does not reference System facade where ValueType lives. As a result ValueTuple was considered a class.
This code would not be emittable in regular compile scenario. It would have diagnostics about missing references.

In reply to: 81644864 [](ancestors = 81644864,81644123)

It is really a result of the changes that makes tuples value types regardless whether backing types are errors or not.

In reply to: 81645389 [](ancestors = 81645389,81644864,81644123)

Could you clarify why this isn't an error in this case?

In reply to: 81645590 [](ancestors = 81645590,81645389,81644864,81644123)

Logged #14267 to report a compile error here.

Thanks! We should either recognize missing ValueType to be a special type (that would make derived types structs) or report an error. Neither is happening.

In reply to: 81822455 [](ancestors = 81822455)

jcouv · 2016-10-03T21:33:11Z

src/Compilers/CSharp/Test/Emit/CodeGen/CodeGenTupleTest.cs

+ // (9,5): error CS8180: Predefined type 'ValueTuple`2' must be a struct.
+ // {
+ Diagnostic(ErrorCode.ERR_PredefinedValueTupleTypeMustBeStruct, @"{
+ return (1, 1);


The area for squiggles seems larger than necessary. Why isn't the error just located on the tuple literal or the method return type? #ByDesign

this is what is passed to that method as a relevant syntax reference from the callers.
I think this is sufficient. This is going to be very rare diagnostics. It does not need to be very user friendly.

In reply to: 81644930 [](ancestors = 81644930)

jcouv

LGTM Thanks

cston · 2016-10-03T21:39:30Z

src/Compilers/CSharp/Portable/Emitter/Model/PEModuleBuilder.cs

+ // this should never happen, in theory,
+ // but if it does happen we should make it a failure.
+ var declaredBase = namedTypeSymbol.BaseTypeNoUseSiteDiagnostics;
+ if (declaredBase.SpecialType != SpecialType.System_ValueType && !declaredBase.IsErrorType())


declaredBase will be null for interface ValueTuple<T1, T2>. #Resolved

Thanks!! Fixed and added a test.

In reply to: 81646014 [](ancestors = 81646014)

cston · 2016-10-03T22:09:43Z

LGTM

AlekseyTs · 2016-10-03T22:22:36Z

src/Compilers/CSharp/Portable/Binder/Binder_Expressions.cs

+ if (node.Type.Kind() == SyntaxKind.TupleType)
+ {
+ Debug.Assert(node.HasErrors, "new <tuple type> should be a syntax error");
+ return BadExpression(node, LookupResultKind.NotCreatable);


return BadExpression(node, LookupResultKind.NotCreatable); [](start = 16, length = 58)

I think we shouldn't cancel the binding short, all constituent parts should be bound and preserved in the tree for SemanticModel benefits. I suggest we simply continue normally as it doesn't look like returning bad expression actually gives us much. #Closed

Agreed. If we happened to parse it (not make a junk trivia), we may as well bind it.
Perhaps should put "HasError" flag on the bound node though. To make sure it does not go further.

In reply to: 81652702 [](ancestors = 81652702)

AlekseyTs · 2016-10-03T22:27:26Z

src/Compilers/CSharp/Portable/Parser/LanguageParser.cs

+ var objectCreation = _syntaxFactory.ObjectCreationExpression(@new, type, argumentList, initializer);
+ if (type.Kind == SyntaxKind.TupleType)
+ {
+ objectCreation = this.AddError(objectCreation, objectCreation, ErrorCode.ERR_NewWithTupleTypeSyntax, type.ToString());


type.ToString() [](start = 121, length = 15)

Do we do this anywhere else? How does this look with line breaks within the type syntax? #Closed

It is more common that we do "currentToken.Text" which also can be multiline.
I think the error will not be nice looking. Multiline errors are not nice looking in general.

I do not think there is a lot of choice here other than not specify the type in the error at all.

In reply to: 81653476 [](ancestors = 81653476)

Error gets truncated. It does look ugly.
I will put squigglies only for the type and not mention the actual type i the error

In reply to: 81658408 [](ancestors = 81658408,81653476)

AlekseyTs · 2016-10-03T22:34:33Z

src/Compilers/CSharp/Portable/Emitter/Model/PEModuleBuilder.cs

+ // Try to decrease noise by not complaining about the same type over and over again.
+ if (_reportedErrorTypesMap.Add(namedTypeSymbol))
+ {
+ diagnostics.Add(new CSDiagnostic(new CSDiagnosticInfo(ErrorCode.ERR_PredefinedValueTupleTypeMustBeStruct, namedTypeSymbol.MetadataName), syntaxNodeOpt == null ? NoLocation.Singleton : syntaxNodeOpt.Location));


diagnostics.Add(new CSDiagnostic(new CSDiagnosticInfo(ErrorCode.ERR_PredefinedValueTupleTypeMustBeStruct, namedTypeSymbol.MetadataName), syntaxNodeOpt == null ? NoLocation.Singleton : syntaxNodeOpt.Location)); [](start = 20, length = 209)

Do we have a test for a nested case. #Closed

nested as in ... example?

In reply to: 81654602 [](ancestors = 81654602)

A tuple of cardinality >= 8 is used and VT`8 is not a structure, or "short" VT is not a structure, or both are not structures. #Resolved

AlekseyTs · 2016-10-03T23:09:27Z

Do we have a test verifying that one can still invoke constructors by using type name?

new ValueTuple<int, long>(1, 2)
```  #Resolved

VSadov · 2016-10-04T00:02:33Z

Yes, we have those. UnifyUnderlyingWithTuple_08 has a bunch.

In reply to: 251253047 [](ancestors = 251253047)

VSadov · 2016-10-04T01:03:00Z

@dotnet-bot test windows_debug_unit32_prtest please

AlekseyTs · 2016-10-04T17:41:30Z

src/Compilers/CSharp/Portable/Emitter/Model/PEModuleBuilder.cs

+ // but if it does happen we should make it a failure.
+ // NOTE: declaredBase could be null for interfaces
+ var declaredBase = namedTypeSymbol.BaseTypeNoUseSiteDiagnostics;
+ if (declaredBase?.SpecialType != SpecialType.System_ValueType && declaredBase?.IsErrorType() != true)


!= true [](start = 104, length = 8)

Is there a test that backs this change? #Closed

ValueTupleNotStruct2i

In reply to: 81812665 [](ancestors = 81812665)

It covers the case where ValueTuple is an interface. (and it was indeed causing a crash)

In reply to: 81813233 [](ancestors = 81813233,81812665)

VSadov added 2 commits September 28, 2016 16:05

Fixes: dotnet#11689

7b5e3d3

Fixes: dotnet#10891

bc1ad9d

dnfclas added the cla-already-signed label Sep 28, 2016

gafter added the Area-Compilers label Sep 29, 2016

gafter suggested changes Sep 29, 2016

View reviewed changes

VSadov added 6 commits September 29, 2016 14:14

CR feedback

593bddf

Merge remote-tracking branch 'refs/remotes/upstream/master'

3f2436b

Updated parser tests

d21d9f7

Merge remote-tracking branch 'refs/remotes/upstream/master'

732407b

adjust EE tests

3f7aac6

merged recent master

2b55e5e

gafter approved these changes Sep 30, 2016

View reviewed changes

added couple small scenarios to parsing tests.

430ffc7

cston reviewed Sep 30, 2016

View reviewed changes

gafter approved these changes Sep 30, 2016

View reviewed changes

VSadov added 2 commits October 1, 2016 07:54

move tuple type binding in object creation past the check for a tuple…

f79bea9

… type syntax

merged recent master

73d4028

jcouv reviewed Oct 3, 2016

View reviewed changes

cston reviewed Oct 3, 2016

View reviewed changes

jcouv reviewed Oct 3, 2016

View reviewed changes

jcouv approved these changes Oct 3, 2016

View reviewed changes

cston reviewed Oct 3, 2016

View reviewed changes

More CR feedback

11355bd

AlekseyTs reviewed Oct 3, 2016

View reviewed changes

More CR feedback

3eacdfd

VSadov merged commit a6236b5 into dotnet:master Oct 4, 2016

AlekseyTs reviewed Oct 4, 2016

View reviewed changes

gafter mentioned this pull request Oct 6, 2016

Tuple reference compiles without System.Runtime.dll #14267

Closed

VSadov deleted the tupStr002 branch June 29, 2017 17:44

Two bug fixes - disallow "new (int, int)()" and induce a failure if ValueTuple is not a struct. #14161

Two bug fixes - disallow "new (int, int)()" and induce a failure if ValueTuple is not a struct. #14161

Conversation

VSadov commented Sep 28, 2016

gafter Sep 29, 2016 • edited by VSadov Loading

Choose a reason for hiding this comment

VSadov Sep 29, 2016 • edited Loading

Choose a reason for hiding this comment

gafter Sep 29, 2016 • edited by VSadov Loading

Choose a reason for hiding this comment

VSadov Sep 29, 2016 • edited Loading

Choose a reason for hiding this comment

VSadov commented Sep 30, 2016

gafter left a comment

Choose a reason for hiding this comment

gafter Sep 30, 2016 • edited by VSadov Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gafter Sep 30, 2016 • edited by VSadov Loading

Choose a reason for hiding this comment

VSadov Sep 30, 2016 • edited Loading

Choose a reason for hiding this comment

VSadov Sep 30, 2016 • edited Loading

Choose a reason for hiding this comment

VSadov Sep 30, 2016 • edited Loading

Choose a reason for hiding this comment

VSadov Sep 30, 2016 • edited Loading

Choose a reason for hiding this comment

gafter Sep 30, 2016 • edited by VSadov Loading

Choose a reason for hiding this comment

VSadov Sep 30, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cston Sep 30, 2016 • edited by VSadov Loading

Choose a reason for hiding this comment

VSadov Sep 30, 2016 • edited Loading

Choose a reason for hiding this comment

VSadov Sep 30, 2016 • edited Loading

Choose a reason for hiding this comment

cston Oct 1, 2016 • edited by VSadov Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

VSadov Oct 1, 2016 • edited Loading

Choose a reason for hiding this comment

cston Sep 30, 2016 • edited by VSadov Loading

Choose a reason for hiding this comment

gafter Sep 30, 2016 • edited by VSadov Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

VSadov commented Oct 3, 2016

jcouv Oct 3, 2016 • edited by VSadov Loading

Choose a reason for hiding this comment

jcouv Oct 3, 2016 • edited by VSadov Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cston Oct 3, 2016 • edited by VSadov Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jcouv Oct 3, 2016 • edited by VSadov Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jcouv Oct 3, 2016 • edited by VSadov Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jcouv Oct 3, 2016 • edited by VSadov Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jcouv Oct 3, 2016 • edited by VSadov Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jcouv left a comment

gafter Sep 29, 2016 •

edited by VSadov

Loading

VSadov Sep 29, 2016 •

edited

Loading

gafter Sep 29, 2016 •

edited by VSadov

Loading

VSadov Sep 29, 2016 •

edited

Loading

gafter Sep 30, 2016 •

edited by VSadov

Loading

gafter Sep 30, 2016 •

edited by VSadov

Loading

VSadov Sep 30, 2016 •

edited

Loading

VSadov Sep 30, 2016 •

edited

Loading

VSadov Sep 30, 2016 •

edited

Loading

VSadov Sep 30, 2016 •

edited

Loading

gafter Sep 30, 2016 •

edited by VSadov

Loading

VSadov Sep 30, 2016 •

edited

Loading

cston Sep 30, 2016 •

edited by VSadov

Loading

VSadov Sep 30, 2016 •

edited

Loading

VSadov Sep 30, 2016 •

edited

Loading

cston Oct 1, 2016 •

edited by VSadov

Loading

VSadov Oct 1, 2016 •

edited

Loading

cston Sep 30, 2016 •

edited by VSadov

Loading

gafter Sep 30, 2016 •

edited by VSadov

Loading

jcouv Oct 3, 2016 •

edited by VSadov

Loading

jcouv Oct 3, 2016 •

edited by VSadov

Loading

cston Oct 3, 2016 •

edited by VSadov

Loading

jcouv Oct 3, 2016 •

edited by VSadov

Loading

jcouv Oct 3, 2016 •

edited by VSadov

Loading

jcouv Oct 3, 2016 •

edited by VSadov

Loading

jcouv Oct 3, 2016 •

edited by VSadov

Loading

cston Oct 3, 2016 •

edited by VSadov

Loading

AlekseyTs Oct 3, 2016 •

edited

Loading

VSadov Oct 3, 2016 •

edited

Loading

AlekseyTs Oct 3, 2016 •

edited

Loading

AlekseyTs Oct 3, 2016 •

edited

Loading

AlekseyTs Oct 3, 2016 •

edited by VSadov

Loading

AlekseyTs commented Oct 3, 2016 •

edited by VSadov

Loading

AlekseyTs Oct 4, 2016 •

edited

Loading